components/inmobile/common/utils.mjs (1)

58-60: Flatten nested arrays and decrement depth in parseArray

Ensure consistent depth handling and normalize nested arrays (common when strings contain JSON arrays).

Apply this diff:

-  if (Array.isArray(input)) {
-    return input.map((item) => parseArray(item, maxDepth));
-  }
+  if (Array.isArray(input)) {
+    return input.flatMap((item) => {
+      const v = parseArray(item, maxDepth - 1);
+      return Array.isArray(v) ? v : [v];
+    });
+  }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

components/inmobile/actions/send-sms-messages/send-sms-messages.mjs (2)

18-55: Critical: Prop type contradicts documentation and example.

The messages prop is declared as string[] (line 18), but the entire description (lines 20-54) documents message objects with fields like to, text, from, etc., and the example (lines 39-53) shows an array of objects—not strings.

This type mismatch will confuse users and break at runtime when the action attempts to use string elements as objects.

Resolution options:

1. Preferred: Change the prop type to accept objects directly so users can pass [{ to: "...", text: "...", from: "..." }] without manual JSON stringification.
2. Alternative: Keep string[] but clarify that each string must be a valid JSON object (not a top-level JSON array), and update the example to show individual stringified objects.

Would you like me to generate the updated prop definition for option 1?

---

63-71: Critical: Missing validation, incorrect count, and nested array risk.

The current implementation has multiple critical issues:

1. No flattening (line 66): utils.parseArray(messages) can return nested arrays if any element is a JSON array string (e.g., ["[{...}, {...}]"] becomes [[{...}, {...}]]), breaking the API call.

2. No message count validation: The InMobile API requires 1-250 messages. This is not enforced.

3. No required field validation: The code doesn't check that each message has to, text, and from fields, leading to cryptic API errors.

4. Incorrect summary (line 70): Uses original messages.length instead of the parsed/flattened count, so the summary may report the wrong number.

5. No idempotency safeguard: Without enforcing or auto-assigning messageId, retries will send duplicate messages.

Apply this diff to address all issues:

+    // Normalize inputs: accept string[], object[], or JSON array strings within the array
+    const normalizedMessages = (Array.isArray(messages) ? messages : [messages])
+      .flatMap((m) => {
+        const v = utils.parseArray(m);
+        return Array.isArray(v) ? v : [v];
+      });
+
+    if (normalizedMessages.length < 1 || normalizedMessages.length > 250) {
+      throw new Error("Messages must contain between 1 and 250 items.");
+    }
+    normalizedMessages.forEach((msg, i) => {
+      if (!msg || typeof msg !== "object") {
+        throw new Error(`Message at index ${i} is not an object.`);
+      }
+      const { to, text, from } = msg;
+      if (!to || !text || !from) {
+        throw new Error(`Message at index ${i} is missing required field(s): to, text, from.`);
+      }
+    });
+
     const response = await app.sendSms({
       $,
       data: {
-        messages: utils.parseArray(messages),
+        messages: normalizedMessages,
       },
     });

-    $.export("$summary", `Successfully sent ${messages.length} SMS message(s)`);
+    $.export("$summary", `Successfully sent ${normalizedMessages.length} SMS message(s)`);
     return response;

Note on idempotency: Consider requiring or auto-assigning messageId for each message to prevent duplicate sends on retries.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro